The present invention relates to methods and apparatus for processing data within a computer network. More specifically, it relates to mechanisms for handling FTP (file transfer protocol) control packets within a data network having IPv4 only devices, IPv6 only devices, and dual-stack devices.
For a particular computer to communicate with other computers or web servers within a network (e.g., the Internet), the particular computer must have a unique IP address. IP protocol version 4 specifies 32 bits for the IP address, which theoretically gives about 4,294,967,296 unique IP addresses. However, there are actually only between 3.2 and 3.3 billion available IP addresses since the addresses are separated into classes and set aside for multicasting, testing and other special uses. With the explosion of the Internet, the number of IP addresses is not enough to give each computer a unique IP address.
One solution for addressing computers with the limited number of IP addresses is referred to as network address translation (NAT). NAT allows an intermediary device (e.g., computer, router or switch) located between the Internet network and a local network to serve as an agent for a group of local computers. A small range of IP addresses or a single IP address is assigned to represent the group of local computers. Each computer within the local group is also given a local IP address that is only used within that local group. However, the group's local IP addresses may duplicate IP address that are used outside of the local network. When a local computer attempts to communicate with a computer outside the local network, the intermediary device matches the local computer's local IP address (and port) to one of the intermediary device's assigned IP addresses (and ports). The intermediary device then replaces the local computer's local address (and port) with the matched assigned IP address (and port). This matched assigned IP address (and port) is then used to communicate between the local computer and the outside computer. Thus, NAT techniques allow IP address to be duplicated across local networks.
Another solution to the lack of available IP addresses is to redesign the address format to allow for more possible IP addresses. The recent introduction of IPv6 provides 128 bits for the IP address, as compared with IPv4 which provides 32 bits for the IP address. However, until all network devices and computers are converted to IPv6, it is still necessary to allow an existing IPv4 device to communicate with an IPv6 device. One popular method that allows IPv4 to IPv6 communication is referred to as protocol translation (NAT-PT). The IP addresses are converted by NAT-PT from one protocol to another protocol (e.g., IPv4 to IPv6 or vice versa). In addition to the IP addresses, the NAT-PT also converts any relevant IPv4 or IPv6 information during a protocol translation. Several embodiments of NAT-PT are described in Internet Engineering Task Force's Request for Comments document RFC 2766, entitled “Network Address Translation—Protocol Translation (NAT-PT)” by G. Tsirtsis and P. Srisuresh (February 2000), which document is incorporated herein by reference in its entirety.
A packet may also contain address(es) embedded in the payload that require translation. Particular applications may embed address(es) in the payload for various application specific purposes, such as DNS (domain name system), FTP (file transfer protocol), or H.225/H.245. Consider a topology where IPv4-only devices, IPv6-only devices and dual-stack devices coexist in a network. The same topology may also contain disparate networks that are IPv4-only (with only IPv4 devices) and networks that are IPv6-only (with only IPv6-devices). With the rising need for moving to IPv6 networks, this kind of topology is a very possible real world situation. In such a topology, and considering the fact that FTP is one of the most commonly used protocols by any IPv4 or IPv6 device, there is an immediate need for any FTP client to be able to use any FTP server. For example, an IPv4 client should be able to download/upload files from an IPv6 server located within the client's network or outside the client's network. Similarly, an IPv6 device should be able to download/upload files from an IPv4 device.
Currently, there are no mechanisms that allow an FTP session between an IPv4 and IPv6 server, and visa versa. In these situations, the FTP control packets have IP addresses (IPv4 or IPv6) embedded in the payload. Also, the commands understood by IPv4 FTP client and IPv4 FTP server are different from the commands understood by IPv6 FTP client and IPv6 FTP server. An IPv4 formatted address and IPv4 formatted control command will not be understood by an IPv6 device. Likewise, an IPv6 formatted address and IPv6 formatted control command will not be understood by an IPv4 device. Therefore, FTP downloads and FTP uploads do not work from IPv4 to IPv6 and vice versa because of the disparate command and address formats.
In view of the above, there is a need for improved mechanisms for facilitating FTP sessions between a client and server which utilize different protocols, such as IPv4 and IPv6.